1. Field of the Invention
Embodiments of the present invention relate to the field of computer software and mechanisms for keeping computer software up-to-date. More specifically, embodiments of the present invention are directed to a technology for updating software on dormant disks.
2. Description of the Related Art
The advantages of virtual machine technology have become widely recognized. Among these advantages is the ability to run multiple virtual machines on a single host platform. This can make better use of the capacity of the hardware, while still ensuring that each user enjoys the features of a “complete” computer. An additional benefit of virtualization, in some implementations, is greater security. For instance, virtualization increases security by isolating potentially unstable or unsafe software so that it cannot adversely affect the hardware state or system files required for running the physical (as opposed to virtual) hardware.
As is well known in the field of computer science, a virtual machine (VM) is a software abstraction, or “virtualization,” of an actual physical computer system. FIG. 1 shows one possible arrangement of a computer system 700 that implements virtualization. FIG. 1 shows a plurality of virtual machines (VMs) 200-200n and a plurality of virtual machine monitors (VMMs) 300-300n, coupled to an exemplary system hardware platform 100. An optional kernel 600 (used in non-hosted systems) is also shown. Additionally, an operating system 420, with applications 430, is shown with optional couplings to system hardware 100 and VMMs 300-300n. 
In FIG. 1, a virtual machine (VM) 200, which in this system is a “guest,” is installed on a “host platform,” or simply “host,” which includes system hardware 100 and one or more layers or co-resident components comprising system-level software, such as OS 420 or similar kernel 600, VMMs 300-300n, or some combination of these. As software, the code defining VM 200 will ultimately execute on the actual system hardware 100.
As in almost all computers, this system hardware 100 will typically include one or more CPUs 110, some form of memory 130 (volatile and/or non-volatile), one or more storage devices such as one or more disks 140, and one or more devices 170, which may be integral or separate and removable. In many existing virtualized systems, the hardware processor(s) 110 are the same as in a non-virtualized computer with the same platform, for example, the Intel x-86 platform. Because of the advantages of virtualization, however, some hardware vendors have proposed, and are presumably developing, hardware processors that include specific hardware support for virtualization.
Each VM 200 will typically mimic the general structure of a physical computer and as such will usually have both virtual system hardware 201 and guest system software 202. The virtual system hardware typically includes at least one virtual CPU 210, virtual memory 230, at least one storage device such as virtual disk 240, and one or more virtual devices 270. Note that virtual disk 240 and physical disk 140 are also “devices,” but are shown separately in FIG. 1 because of the important roles they play. All of the virtual hardware components of VM 200 may be implemented in software to emulate corresponding physical components. The guest system software 202 typically includes a guest operating system (OS) 220 and drivers 224 as needed, for example, for the various virtual devices 270.
To permit computer systems to scale to larger numbers of concurrent threads, systems with multiple CPUs—physical or logical, or a combination—have been developed. One example is a symmetric multi-processor (SMP) system, which is available as an extension of the PC platform and from other vendors. Essentially, an SMP system is a hardware platform that connects multiple processors to a shared main memory and shared I/O devices. Yet another configuration is found in a so-called “multi-core” architecture, in which more than one physical CPU is fabricated on a single chip, with its own set of functional units (such as a floating-point unit and an arithmetic/logic unit ALU), and can execute threads independently; multi-core processors typically share only very limited resources, for example, some cache. Still another technique that provides for simultaneous execution of multiple threads is referred to as “simultaneous multi-threading,” in which more than one logical CPU (hardware thread) operates simultaneously on a single chip, but in which the logical CPUs flexibly share not only one or more caches, but also some functional unit(s) and sometimes also the translation lookaside buffer (TLB).
Similarly, a single VM 200 may (but need not) be configured with more than one virtualized physical and/or logical processor. By way of example, FIG. 1 illustrates multiple virtual processors 210a, 210b, . . . , 210c (VCPU0, VCPU1, . . . , VCPUm) within the VM 200. Each virtualized processor in VM 200 may also be multi-core, or multi-threaded, or both, depending on the virtualization. This invention may be used to advantage regardless of the number of processors the VMs are configured to have.
If VM 200 is properly designed, applications 260 running on VM 200 will function as they would if run on a “real” computer. This occurs even though the applications are running at least partially indirectly, that is via the guest OS 220 and virtual processor(s) (210a-210m). Executable files will be accessed by guest OS 220 from virtual disk 240 or virtual memory 230, which will be portions of the actual physical disk 140 or physical memory 130 allocated to VM 200. Applications may be installed within VM 200 in a conventional manner, using guest OS 220. Guest OS 220 retrieves files required for the execution of such installed applications from virtual disk 240 in a conventional manner.
Some interface is generally required between the guest software within a VM and the various hardware components and devices in the underlying hardware platform. This interface—referred to in this text as “virtualization software”—may include one or more software components and/or layers, possibly including one or more of the software components known in the field of virtual machine technology as “virtual machine monitors” (VMMs), “hypervisors,” or virtualization “kernels.” Because virtualization terminology has evolved over time and has not yet become fully standardized, these terms do not always provide clear distinctions between the software layers and components to which they refer. For example, “hypervisor” is often used to describe both a VMM and a kernel together, either as separate but cooperating components or with one or more VMMs incorporated wholly or partially into the kernel itself; however, “hypervisor” is sometimes used instead to mean some variant of a VMM alone, which interfaces with some other software layer(s) or component(s) to support the virtualization. Moreover, in some systems, some virtualization code is included in at least one “superior” VM to facilitate the operations of other VMs. Furthermore, specific software support for VMs is sometimes included in the host OS itself.
Unless otherwise indicated, the invention described below may be used in virtualized computer systems having any type or configuration of virtualization software. Moreover, the invention is described and illustrated below primarily as including one or more virtual machine monitors that appear as separate entities from other components of the virtualization software. This is only for the sake of simplicity and clarity and by way of illustration—as mentioned above, the distinctions are not always so clear-cut. Again, unless otherwise indicated or apparent from the description, it is to be assumed that the invention can be implemented anywhere within the overall structure of the virtualization software.
As FIG. 1 illustrates, a virtualized computer system may (and usually will) have more than one VM (200-200n), each of which may be running on its own VMM (300-300n). The various virtualized hardware components in VM 200, such as virtual CPU 210, virtual memory 230, virtual disk 240, and virtual device(s) 270, are shown as being part of VM 200 for the sake of conceptual simplicity. In actuality, these “components” are often implemented as software device emulators 330 included in VMM 300. One advantage of such an arrangement is that VMM 300 may (but need not) be set up to expose “generic” devices. Exposing generic devices facilitates, for example, migration of VM 200 from one hardware platform to another.
As FIG. 1 illustrates, a virtualized computer system may (and usually will) have more than one VM (200-200n), each of which may be running on its own VMM (300-300n). The various virtualized hardware components in VM 200, such as virtual CPU 210, virtual memory 230, virtual disk 240, and virtual device(s) 270, are shown as being part of VM 200 for the sake of conceptual simplicity. In actuality, these “components” are often implemented as software device emulators 330 included in VMM 300. One advantage of such an arrangement is that VMM 300 may (but need not) be set up to expose “generic” devices. Exposing generic devices facilitates, for example, migration of VM 200 from one hardware platform to another.
In contrast, another concept, which has yet to achieve a universally accepted definition, is that of “para-virtualization.” As the name implies, a “para-virtualized” system is not “fully” virtualized, but rather the guest is configured in some way to provide certain features that facilitate virtualization. For example, the guest in some para-virtualized systems is designed to avoid hard-to-virtualize operations and configurations, such as by avoiding certain privileged instructions, certain memory address ranges, etc. As another example, many para-virtualized systems include an interface within the guest that enables explicit calls to other components of the virtualization software. For some, para-virtualization implies that the guest OS (in particular, its kernel) is specifically designed to support such an interface. According to this view, having, for example, an off-the-shelf version of Microsoft Windows XP as the guest OS would not be consistent with the notion of para-virtualization. Others define para-virtualization more broadly to include any guest OS with any code that is specifically intended to provide information directly to the other virtualization software. According to this view, loading a module such as a driver designed to communicate with other virtualization components renders the system para-virtualized, even if the guest OS as such is an off-the-shelf, commercially available OS not specifically designed to support a virtualized computer system.
Unless otherwise indicated or apparent, this invention is not restricted to use in systems with any particular “degree” of virtualization and is not to be limited to any particular notion of full or partial (“para-”) virtualization.
In addition to the distinction between full and partial virtualization, two configurations of intermediate system-level software layer(s), “hosted” and “non-hosted,” are in general use. In a hosted virtualized computer system, an existing, general-purpose operating system 420 forms a “host” OS that is used to perform certain input/output (I/O) operations, alongside and sometimes at the request and direction of the VMM 300. The optional coupling between OS 420 and VMM 300 provides one conduit for such communication. In a hosted system, optional kernel 600 is not utilized, and VMM 300 is instead coupled directly to system hardware 100. The host OS in OS 420 and VMM 300 are both able to directly access at least some of the same system hardware resources 100, with conflicts being avoided by a context-switching mechanism. The Workstation product of VMware, Inc., of Palo Alto, Calif., is an example of a hosted, virtualized computer system, which is also explained in U.S. Pat. No. 6,496,847 (Bugnion, et al., “System and Method for Virtualizing Computer Systems,” 17 Dec. 2002).
In a non-hosted system, VMM 300 is deployed on top of an optional software layer called a “hypervisor,” or kernel 600. Kernel 600 is constructed specifically to provide efficient support for VM 300. Compared with a hosted system in which VMM 300 runs directly on the hardware platform, use of kernel 600 offers greater modularity. Use of kernel 600 also facilitates provision of services, such as resource management, that extend across multiple VMs. As contrasted with a hosted environment where kernel 600 is not used, a non-hosted environment may offer greater performance because kernel 600 can be co-developed with VMM 300. Co-development enables optimization of the characteristics of a workload consisting primarily of VMs/VMMs. Additionally, in a non-hosted system, operating system 420 does not utilize the optional coupling shown between OS 420 and VMM 300.
As a generalization, some form of “virtualization software” executes between system hardware 100 and one or more VMs 200. The virtualization software uses the resources of the system hardware 100, and emulates virtual system hardware 201, on which guest system software 202 and guest applications 260 appear to execute. Thus, virtualization software typically comprises one or more device emulators 330 that either include or execute in conjunction with some form of system software for accessing and controlling the system hardware 100. As previously described, the virtualization software may provide full virtualization or partial virtualization. In the non-hosted virtual computer system, the virtualization software primarily comprises VMM 300 and may include some portions of kernel 600. Similarly, in the hosted virtual computer system, the virtualization software primarily comprises VMM 300. Various other configurations for virtualization software and system software are also possible.
Independent of virtualizing the entire operating system of a computer is the concept of virtualizing only the files and storage devices for a computer. Only a few years ago many computers were required to have local disk storage. However, today it is also possible to boot a physical computer or a virtual machine from a virtual disk or from an image that is stored on a server. The increased use of physical computers and of virtual machines, which allow easy proliferation of numerous virtual disks, has lead to a dramatic increase in the number of disks in use. Likewise, many companies and individuals use templates, images, or backups that are static and then applied to machines for booting machines or to configuring machines. Additionally, physical and virtual computers may still use local or remote physical disks, or other physical or logical storage elements that are decoupled from the physical computer via a storage area network (SAN) or internet small computer system interface (iSCSI). Thus, the concept of “disks” includes, but is not limited to, real disks, virtual disks, logical disks, suspended disks, disk snapshots, images, templates, storage area networks, local storage, remote storage, and backup storage.
In an environment that allows so many disk configurations to be created so easily, many of the configurations will often go unused or dormant for some extended period of time such as days, weeks, or longer. A “dormant disk” can be defined as a disk that is not in use. Essentially any file that can be booted or booted from can be considered a dormant disk when it is not in use. A dormant disk typically becomes active when it is booted. However, a dormant disk can become active when it or its contents is attached to a computer (real or virtual) and the computer is powered on.
When unused, dormant disks often go out-of-date, because they do not incorporate the latest updates, such as software and virus related revisions and patches. Starting up such a dormant disk without the latest updates risks exposure to viruses and worms. Additionally, starting up such a dormant disk without the latest updates can cause the computer to attempt to use software which is out-of-date. Even if updates are installed immediately after booting the previously dormant disk, there is still a window of risk of virus infection, attack, or software malfunction. That is, the risks associated with out-of-date disks exist until the out-of-date disk is brought up-to-date. Additionally, a rapid increase in the number of dormant disks is occurring due in part to the trend towards separating storage from computing resources, the rise of “disk imaging” software, and the growing popularity of virtual machine technology, all of which contribute to a proliferation of dormant disks. This increase in dormant disks simply expands the previously described risks.
It should be understood that conventional technologies are only able to update active disks. That is, in order to scan and/or update the software of an active disk, existing solutions depend on the existence of a computer that has booted from the disk. Existing solutions also depend on having the disk's software, especially the operating system, loaded into a computer's memory. These dependencies arise because the existing solutions interact with the loaded operating system in order to coordinate the scan and/or update process for the disk. In an agent-based scanning/updating model, the loaded software includes an agent which interacts with the loaded operating system. While in an agentless scanning/updating model, an external update server interacts with the operating system over a network. In either model, the loaded software typically participates in its own update by writing a newer version of itself onto the activated disk, such that the next time the disk is booted, the newer version will be loaded.
These existing solutions are unable to update a dormant disk since, by definition, no computer has booted from a dormant disk. Instead, these existing “brute-force” methods rely on first booting the dormant disk using a computer to make the disk active. Once the disk is active, the existing scan and/or update processes can then be run. However, booting a disk to perform scans and/or updates creates several problems.
One problem associated with booting dormant disks to perform scans and/or updates is decreased efficiency. The only resource used by a dormant disk is storage space. However, powering on a computer to scan and/or update a dormant disk costs CPU (computer processing unit) cycles and memory. CPU cycles and memory can be scarce resources in a computing environment, especially if the number of dormant disks is large compared to the number of computing resources.
Another problem is rooted in the existing solutions' reliance on a functioning internet protocol. The internet protocol is used to retrieve and deliver the actual updates (patches, revisions, new software versions, virus signatures, and etc.) to the computer that has booted from the disk being updated. If for any reason the network is down when the computer is booted, the computer and its disk cannot be scanned and software updates cannot be delivered to that computer for local installation.
Yet another problem exists because the software to be updated may be required to participate in its own update. For example, consider an update that installs a newer version of the operating system (OS). Suppose that this newer OS version contains a fix to a bug that allows an external network virus to attack and infiltrate the OS. Since the update process temporarily involves running the old version of the OS, booting a dormant disk in order to update it offers a window of vulnerability in which the disk may be compromised, infected, or attacked before the update is installed.
As yet another drawback, in one existing method of scanning and/or updating an out-of-date disk, the out-of-date disk is scanned and/or updated in a quarantined environment. In such an approach a disk is isolated from a network. The disk is then made active and the scanning and/or updating process is started. At this point, a user somehow determines what updates are available and goes about acquiring them. For example, a user can copy all of the updates to a CD-ROM (Compact Disk-Read Only Memory) or DVD-ROM (Digital Versatile Disk-Read Only Memory) using another computer system. These updates are then copied to the quarantined disk so that they can be applied. As this process is done without a network connection to the quarantined disk, it is cumbersome, inconvenient, time consuming, prone to error, and requires extensive human interaction.
With the proliferation of easily created virtual disks and virtual machines as described above, some systems may contain many thousands of potentially dormant disks. Thus, the amount of time spent updating a single dormant disk is multiplied many times for a system or entity that has multiple dormant disks. Hence, the inefficiencies and tedious nature of rendering dormant disks active in order to perform scans and/or updates thereon is a significant problem in today's computing environment.